fix(mcp): read cost totals from the analytics summary - #15355

Summary

• The cost report and three other MCP tools reported totalCost: 0 and requestCount: 0 even though the byProvider breakdown was correct and summed to a real total.
• /api/usage/analytics returns its totals under summary and only honours a range query parameter. The handlers read totalCost, requestCount and per-provider latency from the top level, where those fields do not exist, and passed period=session, which the route ignores.
• One reader now knows the real shape. Totals come from summary. A provider's request count, latency and success rate are aggregated from its byModel rows. A report period maps onto the range values the route accepts. A missing figure is zero.
• pickFastestModel asked for the same ignored period parameter. Its query is corrected. It also reads p95 latency, error rate, tokens per second, time to first token and latency standard deviation, which the analytics route does not return at all. Those stay at zero until the route computes them.

Related Issues

• Closes fix(api): cost_report returns totalCost=0 while byProvider sums correctly (aggregation bug) #15273

Validation

• Change type: other (MCP analytics readers)
• Focused tests: node --import tsx/esm --test tests/unit/mcp-analytics-shape.test.ts (5 pass)
• eslint on the changed files, with the repo suppression file
• Reconciled with release/v3.8.52 @ 69cb18dca8
• New test covers the change
• Defect injection: reading totals instead of summary turns 1 of the 5 tests red, and the change was reverted

Tests Added Or Updated

• tests/unit/mcp-analytics-shape.test.ts (added)

Coverage Notes

• The new test drives readAnalyticsTotals, readProviderMetrics and analyticsRangeForPeriod with the response shape /api/usage/analytics actually returns, including the empty-payload case that yields zeros.

Reviewer Notes

• handleGetProviderMetrics used to fall back to a success rate of 1.0 when the field was missing, which reported "no data" as "100% success". It now reports 0. That is deliberate.
• p50LatencyMs, p95LatencyMs and p99LatencyMs in the provider metrics, and the five speed fields in pickFastestModel, are read from the top level because the analytics route does not compute them. Fixing those means extending the route, which is out of scope here.